home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
TPUG - Toronto PET Users Group
/
TPUG Users Group CD
/
TPUG Users Group CD.iso
/
AMIGA
/
AMICUS
/
AMICUS08.ADF
/
Text
/
Lattice3.03bugs
< prev
next >
Wrap
Text File
|
1986-04-02
|
4KB
|
96 lines
The following is list of bugs (not verified) forwarded from Compuserve:
To those who requested it, here is a list of known bugs in V3.03;
1. fopen() in append mode truncates the file.
2. array subscripting of the form
arr[i].ptr = &arr[n+1]
makes lattice generate incorrect code that results in an addressing
exception.
3. expressions of the form
val += (-8)
generates addq or subq instructions, but does not switch the
sense of the operation as it should.
4. strtol() is busted.
5. pow() loses precision (13th or 14th decimal place.)
Information provided by John Miessien (which I probably just
misspelled horribly, sorry about that)
of Lattice.
sdb
in addition we have found the following bugs with v3.03
1. Unsigned divide by a power of two shifts right by an amount
which is dependent on other things than the constant.
take a look a the generated code the problem is obvious.
basically what goes wrong is that a register is loaded with the
shift count as a long (32 bit) constant....real clever when the
number is for example 3.... and then to top it off, it it loaded
in the top of the register 0x0003nnnn where nnnn is garbage
then the "correct" shift is generated. all this when there
is a shift constant amount instruction. ah well.....
2. unsigned short times unsigned short >> 16 will always return 0
compiler seems to suddenly forget that multiply generates a 32
bit answer and shifts the word part of the register right 16
places
-Metadigm
Doesn't >> have higher precedence the * than *? That would mean shift a 16bit
int right (leaving 0), then multiply.
Just a bit of information -- for all of your complaining about
the Lattice compiler, and drooling over the Aztec compiler.
It is possible to compile Lattice source and end up with
objects smaller than those created with the Aztec compiler. There
is still no contest in speed, the Aztec is faster in all cases.
The trick to with Lattice is to avoid using Lattice standard
routines as found in chapter three of the Lattice C manual. Most
applications can get away with using the EXEC functions, or Intuition
functions for IO, and not need the Lattice (portable) functions.
Amiga.lib even contains various incarnations of the Lattice function
calls (but they are not complete and full functioned, printf for example).
I have recompiled a number of programs and examples (from rkm)
using Astartup.obj and just Amiga.lib. The code ends up on the order
of 2-4k bytes, not 8-16k bytes. This is a significant reduction!
There is no hard and fast rule for knowing if and when you can
get around it. For small programs, you can just compile and link
yourself to see if there are any undefined functions. Simple functions
could even be handcoded and added to your libraries (for future references).
Specifically, the program whereis.c (mailbox AmigaDos) now uses only
2.5k bytes of memory. It seems that the penalty is incurred when using
LC.lib, which calls many varied routines for Lattice support.
This is especially true of printf(), which by itself calls a number
of routines.
If your useage of printf is limited to simple outputs, e.g. printing
error messages, and numbers, and don't require alot of fancy formatting
, or don't perform math within the printf arguments, you can probably
use the version of printf() found in Amiga.lib.
Also, a quick way to chop 3kbytes from your code is to compile your
programs with the option '-v' set during pass 2 (LC2). This eliminates
the stack checking code.
Try it -- and let me know what you think , and whatever else you
can find out.
Thanks.
Randy Weiner <<rweiner>> Commodore Technical Support